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MacWorks Plus: 
Making A Lisa Speak 
Macintosh 


Apple’s Lisa computer never had a chance. Its windows and mice 
were ahead of their time. A nice sports car cost less than a 
minimally-configured Lisa system. And the most significant 
obstacle, which shaped Lisa’s decline and recent return, was 
that Steve Jobs didn’t want it, and for a very good reason. 
Jobs’ pet project, code-named Macintosh, was introduced one 
year after the Lisa at one-third the price. 

But despite the Lisa’s dismal marketing history, it has 
persevered through the efforts of Sun Remarketing in Logan, 
Utah, and a handful of other organizations, the Lisa continues 
to be sold, serviced and supported. My role in this effort has 
been to develop for Sun Remarketing a new Lisa operating 
system called MacWorks Plus. MacWorks Plus allows the Lisa 
to perfectly emulate a Macintosh Plus. It is the successor to a 
program called MacWorks, which was an imperfect emulation 
of a 64K ROM Macintosh. As this is a topic of natural interest 
to the Mac technical community, this article will analyze how 
the old MacWorks functioned, and then address some of the 
obstacles encountered in developing a new one. 


Historical Background A It is asserted in both the Lisa user 
community and some offices in Cupertino that Apple wants to 
kill the Lisa. Though hindsight clearly provides the empirical 
basis for such a claim, it is no longer true. Apple’s new 
willingness to permit the development of MacWorks Plus is 

a welcome confirmation of John Sculley’s changing of 

the guard. 

The survival of the Lisa has always hinged on the Macin- 
tosh. Early in 1984 it was recognized that the Lisa Office 
System alone couldn’t finish off Apple’s inventory of Lisas: 
the Lisa would have to speak Macintosh. And so the spare 
time project of an Apple employee named Rich Castro was 
given official status as MacWorks. This was an implementa- 
tion of the 64K ROM and was sold in conjunction with an 
upgrade kit which converted the Lisa’s rectangular pixels to 
square ones. The Lisa managed to remain attractive because 
you could put up to two megabytes of memory in it as well as 
a 10MB hard disk This was at the time that the Mac sported a 
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meagre 128K of memory, hard disks were nowhere in sight, 
and the “Please Insert The Disk” message was a good friend 
to us all. 

With the introduction of the Mac Plus, however, the Lisa 
lost virtually all of its remaining competitive edge. MacWorks 
was not capable of supporting HFS, Apple Share or the 
increasing number of programs which counted on facilities in 
the 128K ROM and new System Software. These problems 
were felt most acutely at Sun Remarketing. Sun is the only 
company in the world authorized by Apple to sell and service 
its out-of-production equipment. For some time it had also 
been a sounding board for all of the complaints about the Lisa. 
Something had to be done. 


MacWorks A The original MacWorks was the first port of the 
Macintosh Operating System to another computer. The 
architectures of the Lisa and the Macintosh are radically 
different: the Lisa had a memory management unit that 
supported context switching and logical memory mapping, 
but the Macintosh used hard-mapped address lines; the Lisa 
had three expansion slots with DMA support, while the 
Macintosh had none; the Lisa had an intelligent keyboard 
processor with programmable power-on and power-off, but 
the Mac’s keyboard was about as smart as an aardvark. To 
make the Lisa speak Macintosh, it proved necessary to throw 
away the Macintosh hardware interface and provide a 

new one. 

Of course, Apple already had a hardware interface for the 
Lisa. In fact, they had two to choose from: the Lisa Office 
System/Lisa Workshop interface and the Monitor interface. 
The Monitor Operating System was the Lisa’s first develop- 
ment environment. It was essentially a port of the Apple /// 
Pascal Workshop, and as such it inherited the same text-only 
output with single-letter command lines that we all knew and 
loved eight years ago. Monitor OS became Apple’s choice for 
the MacWorks hardware interface for a very good reason: the 
structure of its device drivers and their [/O command blocks 
was almost identical to that used in the Mac. 
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So it was that the Monitor device drivers, some freshly- 
written interrupt handlers and the source code to the Mac 
Toolbox were united into a product called MacWorks. At this 
point Apple also made some design changes to the Lisa and 
began to sell it as the Macintosh XL. It is important to note 
here that these decisions about the design of MacWorks 
established specific limits on its performance and its compati- 
bility with Mac applications, and set the stage for the develop- 
ment of MacWorks Plus. 


The Monitor Operating System A In order to get any type of 
Macintosh emulator running, a system must go through some 
type of bootstrap and load procedure to install the emulator 
and protect it from being, detected and/or overwritten. Also, 
the software environment must be made to look as much as 
possible like that on a Mac before starting the emulator. 

MacWorks did not address this problem very well. 
Because the Monitor OS ran underneath MacWorks, certain 
memory regions had to remain intact across all soft restarts. 
Several of these regions were in low memory where the Mac 
normally locates some of its own information, including the 
trap dispatch tables. Furthermore, Monitor wasted memory 
because its file management kernel was required during 
bootup but then sat idle while MacWorks used its own. This 
difficulty can be understood best by analyzing the bootstrap 
technique used by Monitor. 

The Lisa is the last Apple computer that did not include an 
operating system in the ROM. When a Lisa is powered on, 
there is only enough code in the ROM to perform diagnostic 
tests and boot device selection. Of course, this is the ideal 
machine on which to port the Mac OS, especially given the 
ease with which the Lisa’s MMU can map the emulator’s 
physical memory to the $00400000 range where you would 
expect it ona real Macintosh. Once a boot device is selected, 
the ROM completes stage zero of the boot process by Joading 
sector zero from that device to address $00020000 and 
beginning execution. 

Under Monitor & MacWorks, the 512 bytes of code in 
sector zero must in turn load the initial operating system 
kernel. This kernel may be located anywhere on the disk, so it 
is necessary to put a pointer somewhere that the stage one 
bootcode can find. This is accomplished by putting, an offset 
into the second word of the second sector of the disk. The 
stage one bootcode retrieves this value, subtracts two, and 
positions the device at this sector. It proceeds to load eight 
sectors to address $00020800 and transfers control, 
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Monitor's boot process is extremely flexible, but also 
extremely dependent on specific files. Every bootable Monitor 
disk contains at least four files: MON.LOADER, 
MONITOR.OBJ, CONFIG.DATA and BOOTFILES.DATA. The 
MON.LOADER file contains those eight sectors that are 
loaded by the stage one bovotcode, and the use of the offset in 
sector two is an inexpensive way to avoid a directory search. 
MON.LOADER, however, does contain directory search code, 
and uses it to pull in a sequence of files. First, the 
CONFIG.DATA file is read into memory page one. This 
defines several of the initial low-memory globals required by 
Monitor. Second, MONITOR.OB] is read much higher in 
memory. Finally, BOOTEILES.DATA is read. In this clear-text 
file are a sequence of filenames which are to be read to com- 
plete the boot process. An entry in this file consists of a one- 
byte file type field and a fifteen character name. These files are 
loaded by their order of appearance. When this is complete, 
control transfers to MONITOR.OBJ and the Monitor OS starts. 

While this approach works, it imposes unacceptable 
resource limitations on a MacOS port. The most obvious 
difficulty is that you end up with two file-oriented operating 
systems, one of which is never used after startup. In addition 
to the memory wasted by the unused code, a great deal of 
disk space is idled for overhead like directories for that second 
operating system. This is of particular concern on a hard disk, 
since some type of partitioning scheme is going to be required 
to separate the operating systems. But what does MacWorks 
do? Why, it just copies a complete image of its 400K disk onto 
the hard disk, and then takes an extra 100K for good measure. 
As MacWorks only requires about 100K to begin with, the 
waste is enormous. 

This approach also creates performance limitations 
because every Mac application has to go through two levels of 
calls to do hardware dependent tasks. This includes drawing 
to the screen as well as sound generation and storage 
device 1/0. 


The Macintosh Operating System A If you've ever seriously 
perused the list of low-memory system globals in Iside 
Macintosh, it becomes obvious that the Mac Operating System 
is really portable. “Just look at all of those hardware depend- 
ent parameters, Beaver!” “Gosh, Wally, there's screen size and 
pixel resolution and device addresses and interrupt vectors 
and memory layout and everything. This port’ll be easier than 
eating brussels sprouts!” 
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In all seriousness, Apple has done a fantastic job of 
developing an operating system which is consistent across an 
entire line of computer systems, and which has enormous 
potential for modification and expansion. Indeed, these 
qualities have been exploited by Apple from the first. Apple 
has chosen a relatively expensive method by which to achieve 
this level of consistency: a centralized configuration database 
in the lJow-memory of each Macintosh. It is expensive because 
it costs cycles to look up information that isn’t hard-coded. 
But who cares about expense when it also makes a reconfigu- 
ration of that operating system ona different architecture 
extremely simple? 

This is not to say that Apple has taken all of the work out 
of doing an operating system port. It is a time consuming and 
often frustrating task. However, they have made it possible to 
cleanly separate a hardware dependent kernel from the rest of 
the MacOS. If one replaces this kernel with one for a different 
computer and sets the low-memory globals appropriately, the 
rest needs no modification. This is what Apple did for the 
original MacWorks. 


MacWorks Plus! A Late in 1987 it was clear that something had 
to be done about MacWorks. In addition to the problems 
already described, the fact that it was based on the 64K ROM 
from the original Macintosh meant that it could neither run 
System Software beyond the 5.3/3.2 release, nor could it run 
many applications which depended on later versions of the 
ROM and System Software. Also, Sun Remarketing had devel- 
oped an 800K floppy disk drive for the Lisa as well as HFS, 
but the modifications took up additional memory and 
approximately doubled the system overhead on a hard disk. 
Worse yet, MacWorks would only use 32MB of Sun’s new 
40MB internal hard disk. 

Today, MacWorks Plus has eliminated every one of the 
performance and compatibility problems that plagued its 
predecessor. The vital statistics speak for themselves. Overall 
operating system speed has been improved 25% and Quick- 
draw™ operations run 30% to 40% faster. System Software 
6.0.2 runs perfectly, including MultiFinder™. Applications 
like MPW 2.0.2, HyperCard 1.2.1, Tops 2.0.1, Lightspeed C 3.0, 
TMon 2.81, FullWrite 1.0, Excel 1.5, Crystal Quest 2.2 and 
many more also work perfectly. In addition, MacWorks Plus 
supports a SCSI interface and disk drives of any size. 

The enhancements in MacWorks Plus can be divided into 
three categories: bootcode, hardware interface and operating 
system. The bootcode was completely rewritten, and as a 
result we were able to eliminate wasted code in memory and 
simultaneously cut disk consumption down to 200K. The 
multi-file approach that the Monitor OS used was discarded 
in favor of a single stage two loader which handles memory 
management, machine initialization and loading of the 
MacWorks Plus ROM Image. There are additional advantages 
to this solution. First, operating system globals do not need to 
be preserved, so soft restarts are free to clear all of the 
available memory. Aside from being good programming 
practice to erase all signs of a previous operating system, this 
is crucial to compatibility for some programs. Second, and 
even more important, we could put every system global in its 
proper location. For example, the trap dispatch tables, which 
were located at $00411000 under MacWorks, are now where 
they should be. 
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The second category of enhancements involved rewriting 
the hardware interface. This was also the most time consum- 
ing portion of the project. Wherever possible, we built on code 
from MacWorks, adding control calls and functionality that 
were missing. Unfortunately, this avenue was only open for 
the hard disk driver, AppleTalk drivers, and small pieces of 
the others. The Sony, Sound and Serial drivers were written 
from scratch. Every driver in MacWorks Plus now conforms 
to the specifications in the five volumes of Inside Macintosh. 

One very prominent difference between the 64K and 128K 
ROMs — the handling of device drivers in the ROM — also 
had a major impact on our implementation of a new hardware 
interface. In the 64K ROM, drivers are simply code resources 
that have hard vectors installed in the unit table. Fonts and 
cursors are stored in the same fashion, as well as other system 
information. However, in the 128K ROM Apple decided that 
since these things are resources anyway, they should be stored 
as resources. Hence, the memory from $004176F8 to 
$0041 FFFF on a Mac Plus mimics an open resource file, and 
special hook flags were set up at $000V0BY9E and $00000B9F to 
access it. 

Obviously, all of this information, including the ROM 
resource file map, is hardcoded. The longword at $0040001E 
points to the start of the ROM resource file map, which has a 
format that differs greatly from standard maps. Then the 
resource data begins and continues until the end of the ROM. 
We decided that the simplest way to implement our device 
drivers was just to generate our own complete ROM resource 
file and append it to the MacWorks Plus emulator. We 
included all of the generic resource types in the 128K ROM 
like CRSR, FONT, MDEF and WDEF, and then linked in our 
own. For example, the Sun Remarketing logo which appears 
during bootup ts stored as a PICT in the ROM resource file. A 
highly problematic piece of code was then developed to 
render this standard resource file into a ROM image file and 
append it to the MacWorks Plus ROM image. We were highly 
successful with this technique. Again, we chose to do a little 
extra work to perfect the emulation rather than to kludge it 
and risk incompatibilities. 

Performance improvements are largely the province of the 
operating system, the third category of enhancements. There 
are two types: new features and upgraded features. New 
features include the HFS File Manager, SCSI Manager, List 
Manager, and all of the other system trap calls introduced in 
Inside Macintosh Volume {V. Upgraded features include 
rewrites of several slow subroutines, including Quickdraw 
calls. While these operating system enhancements are the 
most visible of the differences between MacWorks Plus and its 
predecessor, they also took the least amount of time to 
complete. Since all of the MacOS that the user sees is not 
hardware dependent, it can be moved between machines with 
little effort. For example, SCSI support is one of the most 
dramatic improvements for the Lisa, but it took perhaps the 
least effort of all from a software standpoint. So long as the 
SCSI address lines are mapped into precisely the same 
locations in the Lisa as they are in the Mac, then almost no 
code necds to be rewritten to support it. 


Issues for Developers A Any application you write for the 
Macintosh should work under MacWorks Plus subject to one 
proviso: Follow the rules. There are many software packages 
which do not adhere to the guidelines set forth in Juside 
Macintosh, and thanks to a great deal of determined effort and 
some clever system patches they will now run ona Lisa. In 
becoming something of an expert in tracking down such vio- 
lations, it is my experience that they generally fall into two 
categories: environment checks and hardware interfaces. 
Those of you who read comp.sys.mac.programmer have 
already seen my tirade about non-standard environment 
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checks, so I will be brief. There are many applications which 
don’t bother to use _SysEnvirons to determine the runtime en- 
vironment, either because it is quicker to read the low- 
memory global, or because _SysEnvirons is incomplete. A 
good example is the direct check for a floating-point coproces- 
sor at $00500000 that new Microsoft applications perform. 

Hardware interfaces are the second problem area. There 
are applications, for example, which directly reference the 
VIA chip in the Mac. On a Lisa, the VIA is ina different 
location, and so the low-memory global which points to it is 
also different. However, the address of the VIA ina Mac Plus, 
$Q0EFFFFE, is the same as the address of the screenbase 
register ona Lisa. As you might imagine, this generates some 
very pretty crashes. 

I cannot stress enough that this is a Macintosh issue as well 
as a Lisa issue. Given the impending release of System 
Software 7.0 when context switching may become reality and 
references to low-memory globals may cause privilege 
violations, it is smart programming practice to depend as little 
as possible on the physical environment. It is true that Apple 
Developer Technical Services has not been consistent in its 
positions. But that in-and-of-itself is not a reason to disregard 
their current recommendations. Besides, I'd rather have the 
inconsistent positions and volumes of accurate technical infor- 
mation that you get from Apple than the volumes of inaccu- 
rate technical information and total absence of developer 
support that you get from IBM. 

The opinions just presented were not paid for by Apple 
Computer. 


Environment Checking and Debuggers A If for some reason you 
do need to determine if you are on a Lisa, SysEnvirons will 
no longer do it. SysEnvirons will return a Mac Plus. If the 
following comparison is true, then you are running ona Lisa: 
Lisa check 


CMPI.L #'MACW’ ,$00400040; 
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Finally, a few words need to be said about the use of 
debuggers under MacWorks Plus. The popular debuggers 
MacsBug V5.5, Nosy Debugger, and TMon V2.xx all work off- 
the-shelf. Nosy and TMon need no modification to run, and 
MacsBug requires only a replacement of the keyboard input 
routine. This done to the memory image during system 
bootup to avoid requiring a special version. And of course, 
since MacWorks Plus is a robust implementation of the 128K 
ROM, the ROM debugger is also available by pressing the 
NMI button on the back of the Lisa. 


Why MacWorks Plus! Matters to Developers A Software develop- 
ment is a very 1/O bound activity. As programmers, our 
productivity increases at a rate inversely proportional to the 
compile-link cycle time. Those who use our applications also 
benefit when we make sure that they are robust and non- 
hardware dependent. The Lisa with MacWorks Plus can make 
important contributions in both of these areas. As a heavy 
user of both Lightspeed C and MPW, I have been won over by 
the speed difference between my Lisa and my Macintosh SE, 
On compile-link cycles of 30 seconds or more, the Lisa witha 
Sun internal 20MB or 40MB hard disk is always faster than the 
SE with any hard disk whose access rate is over 30ms. To 
compile MacWorks Plus from scratch under MPW takes 20 
minutes on the SE and 17 on the Lisa. The {/O difference is 
even more pronounced given that the Lisa is running 3Mhz 
slower than the Mac. 

A Lisa with MacWorks Plus is also valuable as a sort of 
ToolBox Verification Suite, and is far cheaper than a Mac Il 
with A/UX™, Its 12-inch screen is a godsend for using multi- 
window development systems effectively, especially if a large 
monitor and a video card are outside your budget. 
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